X-Amzn-Trace-Id を使用して Application Load Balancer リクエストをトレースしてみた
2025.01.14はじめに
テクニカルサポートの 片方 です。
今回は ALB とバックエンド側のターゲットの双方で同一のリクエストに関するログを参照しているか否か、判断する方法をご紹介します。
方法について
同一のリクエストであるかを確実に確認する方法としては、ALB が発行するトレース ID の情報をご利用いただく方法がございます。
ALB はターゲットに対してリクエストを送信する際に X-Amzn-Trace-Id ヘッダーを付与し、また、アクセスログを記録する際には X-Amzn-Trace-Id ヘッダーの値を trace_id のフィールドに記録します。
これにより、ターゲット側のログでも X-Amzn-Trace-Id ヘッダーの情報を出力することで、ALB およびターゲットの双方で同一のリクエストに関するログを参照しているかを確認可能です。
"trace_id" X-Amzn-Trace-Id ヘッダーのコンテンツ (二重引用符で囲まれます)。
前提
今回バックエンド側のウェブサーバーは Apache を利用しました。（Amazon Linux 2023 で起動）
ALB のアクセスログ取得方法や、EC2 に Apache インストールする方法などは省かせていただきます。
設定方法が判らない場合は、弊社ブログをご参考ください。
※ ALB アクセスログ
※ ALB + EC2（Apache）
やってみた
ALB のアクセスログを有効化すれば、自動的に X-Amzn-Trace-Id ヘッダーの値を trace_id のフィールドに記録します。
そのため、バックエンド側の Apache ウェブサーバー側の設定を行えば完了です。
お好みの方法で EC2（Apache）に SSH 接続します。
任意のテキストエディタで Apache 設定ファイルを開きます。
$ sudo vi /etc/httpd/conf/httpd.conf
LogFormat セクションで、次のようにオプション ％{X-Amzn-Trace-Id}i を追加します。
LogFormat "%{X-Forwarded-For}i %h %l %u %t \"%r\" %>s %b %D \"%{Referer}i\" \"%{User-Agent}i\" \"%{X-Amzn-Trace-Id}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %b" common
<IfModule logio_module>
# You need to enable mod_logio.c to use %I and %O
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" \"%{X-Amzn-Trace-Id}i\"" combined
Apache サービスを再起動して、次のように変更を適用します。
$ sudo systemctl restart httpd
これで設定は終了です。簡単ですね。
確認してみた
適当にバックエンド側へアクセスを行った後に、ALB 側のアクセスログを確認します。
※ 一部マスクします
http 2025-01-14T08:08:16.668430Z app/Test/cc8ada41cxxxxxxx xxx.1xx.87.xx3:51767 10.0.11.218:80 0.000 0.001 0.000 304 304 557 222 "GET http://test-200xxxxxxx.ap-northeast-1.elb.amazonaws.com:80/ HTTP/1.1" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36" - - arn:aws:elasticloadbalancing:ap-northeast-1:xxxxxxxxxxxx:targetgroup/test-sg/9a5191xxxxxxxxxx "Root=1-67861b70-26f22945248e068a1c4cad1e" "-" "-" 0 2025-01-14T08:08:16.667000Z "forward" "-" "-" "10.0.11.218:80" "304" "-" "-" TID_7ea55c79787470488258e4e381fccaa3
trace_id として "Root=1-67861b70-26f22945248e068a1c4cad1e" が取得されています。
バックエンド側のログを確認します。
$ sudo cat /var/log/httpd/access_log
（略）
10.0.5.74 - - [14/Jan/2025:08:08:16 +0000] "GET / HTTP/1.1" 304 - "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36" "Root=1-67861b70-26f22945248e068a1c4cad1e"
10.0.19.48 - - [14/Jan/2025:08:08:20 +0000] "GET / HTTP/1.1" 200 120 "-" "ELB-HealthChecker/2.0" "-"
ターゲット側のログでも X-Amzn-Trace-Id ヘッダーの情報を出力できていますね。
また、trace_id として同一の "Root=1-67861b70-26f22945248e068a1c4cad1e" が出力されています。成功です！
まとめ
エラーおよびリクエストの遅延調査、パフォーマンス分析に役立つかと思います。
本ブログが誰かの参考になれば幸いです。
参考資料
- Application Load Balancer のアクセスログ
- マネジメントコンソールでALBのアクセスログを有効化してみる | DevelopersIO
- Application Load Balancerを経由してAmazon EC2上のWebページにアクセスする設定をまとめてみた | DevelopersIO
- X-Amzn-Trace-Id を使用して Application Load Balancer リクエストをトレースする | AWS re:Post
アノテーション株式会社について
アノテーション株式会社は、クラスメソッド社のグループ企業として「オペレーション・エクセレンス」を担える企業を目指してチャレンジを続けています。「らしく働く、らしく生きる」のスローガンを掲げ、様々な背景をもつ多様なメンバーが自由度の高い働き方を通してお客様へサービスを提供し続けてきました。現在当社では一緒に会社を盛り上げていただけるメンバーを募集中です。少しでもご興味あれば、アノテーション株式会社WEBサイトをご覧ください。
![[アップデート] AWS Resilience Hub で既存 CloudWatch アラームの統合機能を使ってみた](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-e90f2d5df93382d762eade0c5c825299/23a404c74b6ff29c464743064259e87a/amazon-resilience-hub)
